-
Notifications
You must be signed in to change notification settings - Fork 109
Update litcli for multi-rfq send #1125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update litcli for multi-rfq send #1125
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @GeorgeTsagk, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request primarily focuses on enhancing the litcli command-line interface to fully support the recently introduced multi-RFQ send functionality. It ensures that the client can correctly interpret and present all relevant quote information received during a payment stream, improving the user experience for asset transfers.
Highlights
- Multi-RFQ Send Support: I've updated the
litcliRPC client to correctly parse and display multiple accepted RFQ (Request for Quote) sell orders received in a stream, aligning with the new multi-RFQ send feature intaproot-assets. - Stream Processing Refinement: The
Recvmethod withinresultStreamWrapperhas been refactored to continuously read from the payment stream, handling both individualAcceptedSellOrdermessages (for backward compatibility) and the newAcceptedSellOrdersarray, until the finalPaymentResultis received. - Flag Usage Clarification: The usage description for the
rfq_peer_pubkeycommand-line flag has been updated to clarify that it is now truly optional, and if unset, RFQ peers will be automatically selected.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request updates litcli to handle multiple RFQ quotes from the payment stream. The main change is in the Recv function, which now loops to process different response types, including a new one for a list of quotes.
My review focuses on two points in the new implementation:
- A critical regression that could lead to a panic due to a missing check. I've provided a suggestion to fix this.
- A potential for duplicate output due to the logic for handling legacy and new quote messages. I've explained the issue and suggested a more robust pattern.
Overall, the change correctly addresses the need to handle multiple quotes, but the identified issues should be addressed to ensure correctness and robustness.
674cb93 to
f2b930d
Compare
d59f943 to
4c6c117
Compare
4c6c117 to
f76ce2f
Compare
f76ce2f to
712847f
Compare
f2b930d to
26d9f53
Compare
|
Rebased |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code generally locks good 🚀! Though I lack quite a bit of context to fully understand this change, so generally just reviewing from a code perspective.
Leaving a few questions that could or could not be helpful.
Other then the suggestions above, I think it would also be helpful for reviewers if you add more details to the commit message description.
| "quote when converting from assets to sats; if left " + | ||
| "unset then rfq peers will be picked automatically", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm not seeing that the rest of the changes in this PR actually changes this? If this is due to some other change that's already been merged previously, consider splitting this change into a separate commit and explain why this is now added.
| case *tchrpc.SendPaymentResponse_AcceptedSellOrder: | ||
| err := printQuote(r.AcceptedSellOrder) | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
|
|
||
| return resp.GetPaymentResult(), nil | ||
| legacyFirstPrint = true | ||
|
|
||
| case *tchrpc.SendPaymentResponse_PaymentResult: | ||
| return r.PaymentResult, nil | ||
| case *tchrpc.SendPaymentResponse_AcceptedSellOrders: | ||
| quotes := r.AcceptedSellOrders.AcceptedSellOrders | ||
|
|
||
| default: | ||
| return nil, fmt.Errorf("unexpected response type: %T", r) | ||
| for _, quote := range quotes { | ||
| // If the first item was returned via the legacy | ||
| // field then skip printing it again here. This | ||
| // skip only applies to the first element. | ||
| if legacyFirstPrint { | ||
| legacyFirstPrint = false | ||
| continue | ||
| } | ||
|
|
||
| err := printQuote(quote) | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just checking that this is correct behaviour:
There is no return statement for the *tchrpc.SendPaymentResponse_AcceptedSellOrder & *tchrpc.SendPaymentResponse_AcceptedSellOrders cases here unless there's no error, meaning that they won't break the for loop without any errors being thrown somewhere in the next loop iteration. Is that correct behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah great observation. That's actually how the RPC endpoint behaves.
We'll first return any quote-related information, then we'll follow up with the payment result.
|
Also, this would need release notes updates, whenever this gets merged to |
ec3473a to
d9b6f4c
Compare
26d9f53 to
56df35c
Compare
56df35c to
d009418
Compare
|
With #1155 merged we can now base this off |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only nit comments. I have little context on litd so this is just pure code review.
|
@ViktorT-11: review reminder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good after addressing some of @darioAnongba's feedback!
Also, not sure if you intended to address #1125 (comment) or not?
With the latest version of tapd we no longer require the rfq field to be set. If left unset then AddInvoice/SendPayment will automatically acquire quotes in order for the operation to be carried out.
With the introduction of multi-rfq send in taproot assets (see related PR lightninglabs/taproot-assets#1613) we extended the behavior of the SendPayment RPC slightly. Now we may not specify an RFQ peer in order for a list of peers to be created & used automatically. When that happens, we will return multiple quotes over the RPC. The content of this commit changes our client wrapper around the handling of the payment result. Previously we'd expect for exactly a single quote to be returned over the stream (for the single defined peer). Now we read all of the quotes that are returned in the new quotes array field of the RPC. To maintain backwards compatibility we also kept the previous single-quote RPC field, which we make sure to only read once now that we read both fields (avoid a duplicate quote from appearing in the logs).
d009418 to
8319566
Compare
Description
With the introduction of multi-rfq send we added a new response item in the send payment stream which includes all of the acquired quotes in an array.
This PR updates the RPC client that handles the stream in the context of litcli to correctly read & parse all the possible response items.